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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

The present document is part 2 of a multi-part deliverable covering the Test specification for the Host Controller 
Interface (HCI), as identified below: 

Part 1: "Terminal features (Release 7)"; 

Part 2: "UICC features (Release 7)"; 

Part 3: "Host Controller features (Release 7)". 



Introduction 



The present document defines test cases for the UICC relating to the Host Controller Interface (HCI) as specified in 
TS 102 622 [1]. 

The aim of the present document is to ensure interoperability between the terminal and the UICC independently of the 
respective manufacturer, card issuer or operator. 
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Scope 



The present document covers the minimum characteristics which are considered necessary for the UICC in order to 
provide compliance to TS 102 622 [1]. 

The present document specifies the test cases for: 

• the HCI core as described in the first part of TS 102 622 [1]; 

• the contactless platform as described in the second part of TS 102 622 [1]. 

Test cases for the terminal relating to TS 102 622 [1] and test cases for the Single Wire Protocol (SWP) covering both 
terminal and UICC are out of scope of the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version 
of that document in the same Release as the present document. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 622: "Smart Cards; UICC - Contactless Front-end (CLF) interface; Host Controller 

Interface (HCI)". 

[2] ETSI TS 102 613: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Part 1: Physical 

and data link layer characteristics". 

[3] ISO/lEC 18092: "Information technology - Telecommunications and information exchange 

between systems - Near Field Communication - Interface and Protocol (NFCIP-1)". 

[4] ISO/lEC 14443-3: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 3: Initialization and anticollision". 

[5] ISO/lEC 14443-4: "Identification cards - Contactless integrated circuit cards - Proximity cards - 

Part 4: Transmission Protocol". 

[6] ISO/lEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[7] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics. 

[8] ETSI TS 102 600: "Smart Cards; UICC-Terminal interface; Characteristics of the USB interface". 
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2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not applicable. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 622 [1] and the following apply: 

allowed error response code: response code which is not ANY_OK and which is allowed for the referenced command 
as specified in TS 102 622 [1] 

non-occurrence RQ: RQ which has been extracted from TS 102 622 [1], but which indicates a situation which should 
never occur 

NOTE: The consequence is that such RQs cannot be explicitly tested. 

user: any logical or physical entity which controls the test equipment in a way that it is able to trigger activities of the 
DUT 

3.2 Symbols 

For the purposes of the present document, the symbols given in TS 102 622 [1] and the following apply: 

PIPEq the static pipe connected to the link management gate of the device under test. 

PIPEj the static pipe connected to the administration gate of the device under test. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 622 [1] and the following apply: 

ATQA Answer To reQuest of type A 

ATQB Answer To reQuest of type B 

CLT ContactLess Tunnelling 

DUT Device Under Test 

FFS For Further Study 

FWI Frame Waiting time Integer 

HCI Host Controller Interface 

HCS Host Controller Simulator 

HUT Host Under Test 

ICRx Initial Condition Requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

PICC Proximity Integrated Circuit Card 

PUPI Pseudo-Unique PICC Identifier 

RFU Reserved for Future Use 

RO Read-Only 

RQ conformance Requirement 

RW Read-Write 

SAK Select AcKnowledge 

SFGT Start-up Frame Guard Time 

SRx Static Requirement (where x is a number) 
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NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 
TRx Trigger Requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 
WO Write-Only 



3.4 



Formats 



3.4.1 Format of the table of optional features 

The columns in table 4. 1 have the following meaning. 



Column 


Meaning 


Option 


The optional feature supported or not by the DUT. 


Status 


See clause 3.4.3. 


Support 


The support columns shall be filled in by the supplier of the implementation. The following common 
notations, defined in ISO/IEC 9646-7 [6], are used for the support column in table 4.1 . 
Y or y supported by the implementation. 
N or n not supported by the implementation. 

N/A, n/a or - no answer required (allowed only if the status is N/A, directly or after evaluation of a 
conditional status). 


IVInemonic 


The mnemonic column contains mnemonic identifiers for each item. 



3.4.2 Format of the applicability table 

The applicability of every test in table 4.2 is formally expressed by the use of Boolean expression defined in the 
following clause. 

The columns in table 4.2 have the following meaning. 



Column 


Meaning 


Clause 


The "Clause" column identifies the clause containing the test case referenced in the "Test case number 
and description" column. 


Test case 
number and 
description 


The "Test case number and description" column gives a reference to the test case number (along with 
the corresponding description) detailed in the present document and required to validate the DUT. 


Release 


The "Release" column gives the Release applicable and onwards, for the corresponding test case. 


Execution 
requirements 


The usage of the "Execution requirements" column is described in clause 4.5.2. 


Rel-x UICC 


For a given Release, the corresponding "Rel-x UICC" column lists the tests required for a DUT to be 
declared compliant to this Release. 


Support 


The "Support" column is blank in the proforma, and shall be completed by the manufacturer In respect of 
each particular requirement to indicate the choices, which have been made in the implementation. 
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3.4.3 Status and Notations 

The "Rel-x" columns show the status of the entries as follows: 

The following notations, defined in ISO/IEC 9646-7 [6], are used for the status column: 



mandatory - the capability is required to be supported. 

optional - the capability may be supported or not. 

not applicable - in the given context, it is impossible to use the capability. 

prohibited (excluded) - there is a requirement not to use this capability in the given context. 

qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 
identifies an unique group of related optional items and the logic of their selection which is 
defined immediately following the table. 

conditional - the requirement on the capability ("M", "O", "X" or "N/A") depends on the support 
of other optional or conditional items, "i" is an integer identifying an unique conditional status 
expression which is defined immediately following the table. For nested conditional expressions, 
the syntax "IF ... THEN (IF ... THEN ... ELSE...) ELSE ..." shall be used to avoid ambiguities. 

References to items 

For each possible item answer (answer in the support column) there exists a unique reference, used, for example, in the 
conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item 
number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters 
(a, b, etc.), respectively. 



M 
O 

N/A 

X 

O.i 

Ci 



EXAMPLE: 



4. 1/4 is the reference to the answer of item 4 in table 4. 1 . 



4 Test environment 

4.1 Table of optional features 

The device supplier shall state the support of possible options in table 4.1. See clause 3.4 for the format of table 4.1. 

Table 4.1 : Options 



Item 


Option 


Status 


Support 


Mnemonic 


1 


Link management gate supported 







LINK MAN 


2 


WHITELIST contains the H|p of at least one furtlier 
host 







0_WHITELIST_NON_EMPTY 


3 


Data link layer specified in TS 102 613 [2] is being used 







102 613 



4.2 Applicability table 

Table 4.2 specifies the applicability of each test case to the device under test. See clause 3.4 for the format of table 4.2. 

Clause 4.5.2 should be referenced for usage of the execution requirements which are referenced in table 4.2 a) and 
described in table 4.2 c). 

Table 4.2 a): Applicability of tests 



Clause 


Test case number and description 


Release 


Execution 
requirements 


Rel-7 
UICC 


Support 


5.1.2.2 


Test case 1 : processing of RFU host identifier 


Rel-7 




M 




5.1.3.2 


Test case 1 : existence of gates 


Rel-7 




M 




5.1.3.3 


Test case 2: processing of RFU gate identifier 


Rel-7 




M 
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Clause 


Test case number and description 


Release 


Execution 
requirements 


Rel-7 
UICC 


Support 


5.1.4.2 


Test case 1 ; static pipe deletion - administration gate 


Rel-7 




M 




5.1.4.3 


Test case 2: static pipe deletion - link management gate 


Rel-7 




C101 




5.1.4.4 


Test case 3: persistence of pipe state 


Rel-7 




M 




5.1.4.5 


Test case 4: initial pipe state 


Rel-7 




M 




5.1.5.2 


Test case 1 : registry creation 


Rel-7 


SRI 


M 




5.1.5.3 


Test case 2: registry deletion 


Rel-7 


SR2 


M 




5.2.2.2 


Test case 1 : commands/events on pipe which is not open 


Rel-7 




M 




5.3.1.2.1.2 


Test case 1 : ANY_SET_PARAI\/IETER reception - invalid 
structure 


Rel-7 


SR3 


M 




5.3.1.2.1.3 


Test case 2: ANY_SET_PARAI\/IETER reception - RO 
registry parameter 


Rel-7 




M 




5.3.1.2.2.2 


Test case 1 : ANY_GET_PARAIVIETER reception - invalid 
structure 


Rel-7 




M 




5.3.1.2.2.3 


Test case 2: ANY_GET_PARAMETER reception - WO 
registry parameter 


Rel-7 


SR4 


M 




5.3.1.2.3.2 


Test case 1 : ANY OPEN PIPE reception 


Rel-7 




M 




5.3.1.2.3.3 


Test case 2: ANY OPEN PIPE transmission 


Rel-7 


TR1 


M 




5.3.1.2.4.2 


Test case 1 : ANY CLOSE PIPE reception 


Rel-7 




M 




5.3.1.2.4.3 


Test case 2: ANY CLOSE PIPE transmission 


Rel-7 


TR2 


M 




5.3.2.2 


Test case 1 : response to unknown command 


Rel-7 




M 




5.3.2.3 


Test case 2: responses received out of order, previous 
command sent by host controller 


Rel-7 




M 




5.3.2.4 


Test case 3: responses received out of order, previous 
command sent by host 


Rel-7 


TR1 


M 




5.3.3.2 


Test case 1 : reception of unknown events 


Rel-7 




M 




5.4.1.2 


Test case 1 : command and event support for link 
management gate 


Rel-7 




C101 




5.4.1.3 


Test case 2: command and event support for host 
administration gate 


Rel-7 




M 




5.4.2.1.1.2 


Test case 1 : SESSION IDENTITY 


Rel-7 




M 




5.4.2.1.1.3 


Test case 2: WHITELIST 


Rel-7 


TR3 


M 




5.4.2.2.1.2 


Test case 1 : REC ERROR 


Rel-7 


TR4 


C101 




5.4.2.2.2.2 


Test case 1 : REC ERROR 


Rel-7 


ICR1 


C101 




5.4.2.3.1.2 


Test case 1 : registry parameters 


Rel-7 




M 




5.5.1.1.2 


Test case 1 : ADM CREATE PIPE 


Rel-7 


TR5 


M 




5.5.1.1.3 


Test case 2: ADM_NOTIFY_PIPE_CREATED from host 
controller 


Rel-7 




M 




5.5.1.1.4 


Test case 3: ADM_NOTIFY_PIPE_CREATED from other 
host 


Rel-7 




CI 02 




5.5.1.1.5 


Test case 4: ADM_NOTIFY_PIPE_CREATED with 
incorrect destination H|p 


Rel-7 




M 




5.5.1.1.6 


Test case 5: unsuccessful 
ADM NOTIFY PIPE CREATED 


Rel-7 


SR5 


M 




5.5.1.2.2 


Test case 1 : sending ADM DELETE PIPE 


Rel-7 


TR6 


M 




5.5.1.2.3 


Test case 2: receiving ADM NOTIFY PIPE DELETED 


Rel-7 




M 




5.5.1.3.2 


Test case 1 : ADM CLEAR ALL PIPE for data link layer 
specified in TS 102 613 [2] 


Rel-7 




CI 03 




5.5.1.3.3 


Test case 2: ADM_CLEAR_ALL_PIPE - static pipes, 
dynamic pipes to host controller 


Rel-7 




CI 03 




5.5.1.3.4 


Test case 3: ADM_CLEAR_ALL_PIPE - dynamic pipes to 
other host 


Rel-7 




CI 02 




5.5.1.3.5 


Test case 4: ADM_CLEAR_ALL_PIPE - registry 
parameters 


Rel-7 


ICR1 


C101 




5.5.4.2 


Test case 1 : SESSION IDENTITY not changed 


Rel-7 




CI 03 




5.5.4.3 


Test case 2: SESSION IDENTITY changed 


Rel-7 




CI 03 




5.5.5.2 


Test case 1 : pipe creation from host controller 


Rel-7 




M 




5.5.5.3 


Test case 2: pipe creation from another host 


Rel-7 




CI 02 




5.5.5.4 


Test case 3: processing of EVT POST DATA 


Rel-7 




M 
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Table 4.2 b): Conditional items referenced by table 4.2 a) 



Conditional item 


Condition 


Description 


C101 


IF 4.1/1 THEN MELSEN/A 


LINK MAN 


C102 


IF 4.1/2 THEN MELSEN/A 


WHITELIST NON EMPTY 


C103 


IF 4.1/3 THEN MELSEN/A 


102 613 



Table 4.2 c): Execution requirements referenced by table 4.2 a) 



Execution 
requirement 



Description 



SRI 



A gate which accepts multiple dynamic pipes and has a RW registry parameter; the default value of 
the registry parameter must be known. 



SR2 



A gate which has a RW registry parameter; the default value of the registry parameter must be known. 



SR3 



A gate which contains at least one writeable (i.e. RW or WO) registry parameter. 



SR4 



A gate which contains at least one WO registry parameter. 



SR5 



A G|Q exists which is reserved for proprietary use or is host specific according to table 2 of 
TS 102 622 [1], and which is not contained in the GATES_LIST of the host. 



TR1 



Trigger the host to open PIPE_ID_MAN. 



TR2 



Trigger the host to close PIPE_ID_MAN. 



TR3 



Trigger the host to write its value of WHITELIST into the registry of the host controller's administration 
gate. 



TR4 



Trigger the host to write a value of REC_ERROR into the registry of the host controller's link 
management gate in order to restart an error rate measure. 



TR5 



Trigger the host to create a pipe. 



TR6 



Trigger the host to send ADM_DELETE_PIPE on PIPE, to delete PIPE_LOOP_BACK. 



ICR1 



The last value of REC_ERROR in the host's registry for PIPE^ is not '0000'. 



NOTE: Clause 4.5.2 should be referenced for the meaning and usage of the execution requirements which are 
described in table 4.2 c). 

4.3 Information to be provided by the device supplier 

The device supplier shall provide the information indicated in table 4.3. 

Table 4.3: Default configuration 



Item 


Description 


Presence/Value 


Status 


IVInemonic 


1 


Indication of presence of VERSION_SW, and value if 
supported. 




M 


V_VERSION_SW 


2 


Indication of presence of VERSION_HARD, and 
value if supported. 




M 


V_VERSION_HARD 


3 


Indication of presence of VENDOR_NAME, and value 
if supported. 




M 


V_VENDOR_NAME 


4 


Indication of presence of MODEL_ID, and value if 
supported. 




M 


V_MODEL_ID 


5 


Indication of presence of HCI_VERSION, and value if 
supported. 




M 


V_HCI_VERSION 


6 


Value of GATES LIST. 




M 


V GATES LIST 


NOTE: Conditional values shall be provided if the corresponding option is supported in the table 4.1 . 



4.4 Test equipment 



The test equipment shall provide a host controller simulator which is connected to the DUT during test procedure 
execution, unless otherwise specified. For test cases which require a further host to be present, the test equipment shall 
further provide a host simulator which is connected to the DUT via the host controller simulator during test procedure 
execution, unless otherwise specified. 
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Before execution of each test case, the host network state shall be set back to the state in which it was after the UICC 
was powered up in full power mode using the default SESSION_IDENTITY (in order to instigate a new HCI session 
initialization). 

With respect to the DUT, the host controller simulator shall act as a valid host controller according to TS 102 622 [1] 
unless otherwise specified. In particular, the host controller simulator shall ensure that the values of HOST_LIST and 
GATES_LIST are valid, according to the particular requirements of the test case being executed. 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure that the value GATES_LIST is valid, according to the particular 
requirements of the test case being executed. 

With respect to the DUT, the host network simulation (i.e. host controller simulator and any host simulators) shall 
comprise a valid network according to the specific DUT. The details are out of the scope of the present document. 

4.4.1 Measurement/setting uncertainties 

Void. 

4.4.2 Default conditions for DUT operation 

Unless otherwise specified, the test equipment shall apply the default conditions described in the following clauses 
during test procedure execution. 

4.4.2.1 General 

The test equipment shall treat the identity check mechanism of the lower layer as having passed (see TS 102 622 [1], 
clause 8.4). 

The test equipment shall use the same SESSION_IDENTITY on power up within an individual test case. 

4.4.2.2 Status of UICC interfaces 

If the data link layer in TS 102 613 [2] is used and the DUT is a UICC, the terminal simulator shall not activate the 
TS 102 221 [7] interface or the TS 102 600 [8] interface. 

4.4.3 Minimum/maximum conditions for DUT operation 

Void. 

4.4.4 Conventions 

Unless otherwise specified, ADM_NOTIFY_PIPE_CREATED is sent by the test equipment with source Hjj-, = Hjj-, of 
host controller, destination Hj^ = H^^ of host and a currently unused Pj^. 

If the pipe for a response is not explicitly specified, then the pipe for the response is required to be the pipe on which the 
preceding command was sent. 
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4.5 



Test execution 



4.5.1 Parameter variations 

Unless otherwise specified, when the data link layer in TS 102 613 [2] is used, all tests shall be carried out once for 
each of following parameter variations in addition to the parameter variations specified individually for each test case. 

Table 4.5.1 : Global parameter variations 



Voltage class and power 
mode 


Vcc 


B 


Default: in the range of 2,90 V to 3,10 V 


Minimum: in the range of 2,70 V to 2,80 V 


Maximum: in the range of 3,20 V to 3,30 V 


C, full power 


Default: in the range of 1 ,75 V to 1 ,85 V 


Minimum: in the range of 1 ,62 V to 1 ,67 V 


Maximum: in the range of 1 ,93 V to 1 ,98 V 


C, low power 


Default: in the range of 1 ,75 V to 1 ,85 V 


Minimum: in the range of 1 ,62 V to 1 ,67 V 


Maximum: in the range of 1 ,93 V to 1 ,98 V 



The specification of global parameter variations for when other data link layers are used is out of the scope of the 
present document. 

4.5.2 Execution requirements 

Table 4.2, "Applicability of tests", specifies "execution requirements" for several test cases. For these test cases, it has 
not been possible to specify the corresponding test procedure in such a way that it can be guaranteed that the test 
procedure can be executed against every possible DUT. 

Some sample scenarios of test requirements are listed below: 

• The test case requires certain state to be present on the DUT in order to test a particular feature, but there is no 
mandatory requirement in the core specification (TS 102 622 [1]) for this state to be present. 

• The test case requires the DUT to perform a particular operation in order to test that feature, but the core 
specification (TS 102 622 [1]) does not provide a standardized mechanism to trigger that operation to be 
executed by the DUT. 

The test requirements have been split into various categories, as indicated by table 4.2 c): 

• Static requirements (SRx): information about, for example, particular gates or registry parameters which can 
be used in the test procedure execution. 

• Trigger requirements (TRx): mechanisms for triggering the DUT to perform certain operations. 

• Initial condition requirements (ICRx): information about how to establish initial condition states. 

The DUT supplier should make every effort to provide appropriate information or mechanisms to allow these execution 
requirements to be satisfied for the DUT. 

It is recognized that this might not always be possible. For example, if the configuration of the DUT does not allow for 
the required state to be present; or if it is not possible to provide a particular trigger mechanism for the DUT. In these 
cases, it is acceptable that the test case is not carried out. However, it should be recognized that the consequence is that 
the particular feature will not be tested. 
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4.6 Pass criterion 

A test shall only be considered as successful, if the test procedure was carried out successfully under all parameter 
variations with the DUT respecting all conformance requirements referenced in the test procedure. This is subject to the 
additional qualifications described in clause 4.6.1. 

NOTE: Within the test procedures, the RQs are referenced in the step where they are observable. In some cases 
this is different from the step where they occur with respect to the DUT. 

4.6.1 Unanticipated beinaviour from tine DUT 

In the specification of the test procedures, every attempt has been made to ensure that the interface between the 
simulator and the DUT is in a known state before and during test procedure execution. However, as the DUT is an 
autonomous device, it is not possible to fully guarantee this. 

If the DUT unexpectedly closes or deletes a pipe which is intended to be used during a subsequent part of the test 
procedure, this should not be considered as a failure of the DUT, even though the test procedure cannot be completed 
successfully. Instead, the test procedure should be executed again to attempt to execute the test procedure to 
completion. If the unexpected behaviour occurs again, further effort should be applied by the tester to attempt to ensure 
that the unexpected behaviour does not occur. 



5 Test cases 

5.1 HCI arclnitecture 

5.1.1 Overview 

Reference: TS 102 622 [1], clause 4.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.1.2 Hosts 

5.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.2. 



RQ1 



RQ2 



A host shall not use host identifiers which are RFU. 



A host shall reject received host identifiers which are RFU. 



NOTE: RQl is a non-occurrence RQ. 

5.1 .2.2 Test case 1 : processing of RFU host identifier 

5.1.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Source Hjp values of: every Hjq value which is RFU as defined in TS 102 622 [1]. 

5.1.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 
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5.1.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with the specified source 
H|Q, source G|q = '01' and destination G|q = G|d of loop bacl< gate. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.1.3 Gates 

5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.3. 



RQ1 



All hosts shall have one administration gate. 



RQ2 



All hosts shall have one identity management gate. 



RQ3 



All hosts shall have one loop back gate. 



RQ4 



A host shall not use gate identifiers which are RFU. 



RQ5 



A host shall reject received gate identifiers which are RFU. 



RQ6 



A host shall not use gate identifiers which are host specific but not yet allocated in TS 102 622 [1]. 

A host shall reject received gate identifiers which are host specific but not yet allocated in TS 102 622 [1] 
RQ4 and RQ6 are not tested, as they are non-occurrence RQs. 



RQ7 



NOTE 



NOTE: Development of test cases for RQ7 is FFS. 

5.1 .3.2 Test case 1 : existence of gates 

5.1.3.2.1 Test execution 

5.1.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEj is open. 



5.1.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and 
destination G|q = G|q of identity management gate; designate the created 
pipe PIPE ID MAN. 




2 


HUT ^ HCS 


Send ANY_OK (parameters are not checked). 


RQ1, 
R02 


3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


5 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




6 


HUT ^ HCS 


Send ANY_OK. 

Check that the GATES_LIST returned contains the G|q of the identity 

management gate and the G|q of the loop back gate. 


RQ2, 
RQ3 


7 


HCS^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source 0,0 = '01' and 
destination G|p = G|q of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


R03 


9 


HCS^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




10 


HUT -» HCS 


Send ANY OK (parameters are not checked). 


RQ3 


11 


HCS^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




12 


HUT ^ HCS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


R03 
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5.1.3.3 



Test case 2: processing of RFU gate identifier 



5.1.3.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Destination Gjq values of: every Gjjj value which is RFU as defined in TS 102 622 [1]. 

5.1.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.1.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|o = G^^ of 
identity management gate and the specified destination G|q. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ5 



5.1.4 Pipes 



5.1.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.4. 



RQ1 



A host shall not attempt to delete a static pipe. 



RQ2 



A host shall reject any attempts to delete a static pipe. 



RQ3 



The state of a pipe (i.e. open or closed) shall remain persistent if the hosts are powered down and up again. 



RQ4 



The state of a dynamic pipe after creation shall be closed. 



RQ5 



The initial state of a static pipe shall be closed. 



RQ6 |A host shall not use pipe identifiers which are RFU. 



NOTE: RQ1 and RQ6 are not tested, as they are non-occurrence RQs. 



NOTE: RQS is not tested, as it is not clear when the initial state of the static pipe applies. 

5.1 .4.2 Test case 1 : static pipe deletion - administration gate 

5.1.4.2.1 Test execution 

5.1.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.1.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_DELETED(PIPEi) on PIPE^. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ2 
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5.1 .4.3 Test case 2: static pipe deletion - link management gate 

5.1 .4.3.1 Test execution 

5.1.4.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.1.4.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -» HUT 


Send ADM_NOTIFY_PIPE_DELETED(PIPEo) on PIPE^. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.1 .4.4 Test case 3: persistence of pipe state 

5.1 .4.4.1 Test execution 

5.1.4.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.1.4.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|o = '01' and 
destination G|p = G|q of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




2 


HUT ^ HCS 


Send ANY OK. 




3 


HCS^ HUT 


Power down host. 




4 


HCS -^ HUT 


Power up host, and proceed until the HCI interface is available. 




5 


HCS^ HUT 


Send ANY_CLOSE_PIPE on PJPE^. 




6 


HUT ^ HCS 


Send ANY OK. 


RQ3 


7 


HCS^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ3 


9 


HCS^ HUT 


SendEVT POST DATA on PIPE LOOP BACK. 




10 


HUT ^ HCS 


Send no message on PIPE LOOP BACK. 


RQ3 


11 


HCS^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




12 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ3 



5.1 .4.5 Test case 4: initial pipe state 

5.1.4.5.1 Test execution 

5.1.4.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE I is open. 
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5.1.4.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source G|d = '00' and 
destination G|q = G^q of identity management gate; designate the created 
pipe PIPEx. 




2 


HUT-^HCS 


Send ANY OK. 




3 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPEx. 




4 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 



5.1.5 Registries 



5.1.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.5. 



For all gates defined in TS 102 622 [1], parameter identifiers in the range of '00' to 'EF' are reserved for 
use in TS 102 622 [1]. 



RQ1 



RQ2 



A new instance of the registry is created for every pipe that connects to the gate. 



RQ3 



Upon pipe creation all registry parameters with access rights Read-write (RW) or Write-only (WO) shall 
be set to their default values. 



RQ4 



Upon pipe creation all read-only (RO) parameters shall be set by the entity managing the registry to an 
appropriate value which may differ from the default values. 



R05 



When a pipe is deleted its registry instance is also deleted. 



NOTE: As the specification of registry parameters is specific to each individual registry, RQl, RQ3 and RQ4 are 
not tested in this clause, but are tested in other clauses of the present document for each individual 
registry. 

5.1 .5.2 Test case 1 : registry creation 

5.1 .5.2.1 Test execution 

Assignment of terms to entities referenced in SRI: Gjj-, of gate = GATE_X, registry parameter 
identifier = REG_PARAM. 

5.1.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEj is open. 



£75/ 



Release 7 



22 



ETSI TS 102 695-2 V7.2.0 (2010-10) 



5.1.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source G|d = '01' and 
destination G|q = GATE_X; designate the created pipe PIPEa. 




2 


HUT^HCS 


Send ANY OK (parameters are not checl<ed). 




3 


HCS ^ HUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEa, with a value 
different from the default value. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




5 


HCS -> HUT 


Send ADM_NOTIFY_PIPE_CREATE on PIPE^, with source 0,0 = '01' and 
destination G|q = GATE_X; designate the created pipe PIPEb. 




6 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




7 


HCS^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPEb. 




8 


HUT ^ HCS 


Send ANY OK with parameter value equal to the default value of 
REG PARAM. 


RQ2 


9 


HCS -^ HUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEb, with a value 
different from the default value, and different to the value set in step 3. 




10 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




11 


HCS ^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPEa. 




12 


HUT ^ HCS 


Send ANY_OK with parameter value equal to the value set in step 3. 


R02 



5.1 .5.3 Test case 2: registry deletion 

5.1.5.3.1 Test execution 

Assignment of terms to entities referenced in SR2: Gjj-, of gate = GATE_X, registry parameter 
identifier = REG_PARAM. 

5.1.5.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5. .5.3.3 



Test procedure 



step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d = '01' and 
destination G|q = GATE_X; designate the created pipe PIPEa. 




2 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




3 


HCS ^ HUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEa, with a value 
different from the default value. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




5 


HCS^ HUT 


Send ADM_NOTIFY_PIPE_DELETED(PIPEa) on PIPE^. 




6 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




7 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with G|d = GATE_X; 
designate the created pipe PIPEb. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




9 


HCS^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPEb. 




10 


HUT ^ HCS 


Send ANY OK with parameter value equal to the default value of 
REG PARAM. 


RQ5 
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5.2 



HCP 



5.2.1 HCP packets 

5.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.1. 



RQ1 



RQ2 



RQ3 



All hosts shall use the correct structure for transmitted HCP packets. 



All hosts shall recognize correctly structured received HCP packets. 



The destination host forwards the packet to the destination gate. 



NOTE 1: RQl and RQ2 are implicitly tested by the testing of higher layers in other clauses of the present 
document. 

NOTE 2: RQ3 is internal to the host, and is not tested in this clause. It will be implicitly tested in many other test 
cases within the present document. 



5.2.2 HCP message structure 
5.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.2. 



RQ1 



All hosts shall use the correct structure for transmitted HCP messages. 



RQ2 



Type value 3 shall not be used. 



RQ3 



All hosts shall recognize correctly structured received HCP messages. 



RQ4 



A gate shall only accept a command or an event on a pipe when the state of that pipe is open unless 
otherwise stated. 



RQ5 



A gate shall not send a command or event on a pipe when it is waiting for a response to a previous 
command on that pipe unless otherwise stated. 



NOTE 1: RQl and RQ3 are implicitly tested by the testing of higher layers in other clauses of the present 
document. 

NOTE 2: RQ2 and RQ5 are not tested, as they are non-occurrence RQs. 

5.2.2.2 Test case 1 : commands/events on pipe which is not open 

5.2.2.2.1 Test execution 

5.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 
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5.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPEi, with source and 
destination G|q = G^q of identity management gate; designate the created 
pipe PIPE ID MAN. 




2 


HUT-^HCS 


Send ANY OK (parameters are not checl<ed). 




3 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




4 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 


5 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




6 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




7 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




8 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ4 


9 


HCS^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




10 


HUT -^ HCS 


Send ANY OK (parameters are not checked). 




11 


HCS^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




12 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ4 


13 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source 0,0 = 'GO' and 
destination G|q = G|d of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




14 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




15 


HCS -» HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




16 


HUT ^ HCS 


Send no message on PIPE LOOP BACK. 


RQ4 


17 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




18 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




19 


HCS^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




20 


HUT -» HCS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


RQ4 


21 


HCS^ HUT 


Send ANY CLOSE PIPE on PIPE LOOP BACK. 




22 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




23 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




24 


HUT ^ HCS 


Send no message on PIPE LOOP BACK. 


RQ4 


25 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




26 


HUT ^ HCS 


Send ANY_OK (parameters are not checked). 


RQ4 



5.2.3 Message fragmentation 



5.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 5.3. 



R01 



Message fragmentation shall be used when the size of the message is larger than supported by the 
underlying data link layer. 



R02 



Messages shall be fragmented according to the rules specified in TS 102 622 [1] 



R03 



The destination gate is responsible for rebuilding the message from the fragmented messages. 
If a reset of the underlying data link layer occurs, fragments of a partially received message shall be 
discarded and a partially sent message shall be re-sent from the beginning. 



R04 



NOTE: Development of test cases for RQ 1 , RQ2, RQ3 and RQ4 is FFS . 
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5.3 Instructions 

5.3.1 Commands 

5.3.1.1 Overview 

5.3.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.1. 



RQ1 



For all gates, hosts shall not use RFU instruction values ('05' to 'OF') in commands. 



RQ2 



For administration gates, hosts shall not use RFU instruction values ('16' to '3F') in commands. 



RQ3 



For gates defined in TS 102 622 [1], hosts shall not use instruction values between '10' and '3F' which 
are not allocated in TS 102 622 [1]. 



NOTE: RQl, RQ2 and RQ3 are not tested, as they are non-occurrence RQs. 

5.3.1.2 Generic commands 

5.3.1.2.1 ANY_SET_PARAMETER 

5.3.1 .2.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.1. 



RQl 



A host shall reject an incorrectly formatted ANY_SET_PARAMETER command. 



RQ2 



A host shall reject an ANY_SET_PARAMETER command if the access right for the parameter does not 
allowed writing (i.e. is not RW or WO). 



RQS 



A host shall not send an ANY_SET_PARAI\/IETER command if the access right for the parameter does 
not allow writing (i.e. is not RW or WO). 



RQ4 



When a host receives a valid ANY_SET_PARAMETER command, it shall write the parameter value into 
the registry and respond with ANY_OK without any parameters. 



RQS 



Whenever a host sends an ANY_SET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have at least one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 

• The parameter value shall be a valid value as defined for the specific gate. 



NOTE 1 : RQ3 is not tested, as it is a non-occurrence RQ. 

NOTE 2: RQ4 and RQS are not tested in this clause, as they are effectively tested in other clauses of the present 
document for each individual registry parameter. 

5.3.1 .2.1 .2 Test case 1 : ANY_SET_PARAMETER reception - invalid structure 

5.3.1.2.1.2.1 Test execution 

Assignment of terms to entities referenced in SR3: Gjp of gate = GATE_X. 

5.3.1.2.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_X) has been created to the gate with Gjp = GATE_X, and is open. 
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5.3.1.2.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS-^ HUT 


Send ANY SET PARAMETER with no parameters on PIPE X. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ1 



5.3.1.2.1.3 
5.3.1.2.1.3.1 



Test case 2: ANY_SET_PARAMETER reception - RO registry parameter 
Test execution 



5.3.1.2.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 

5.3.1.2.1.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_SET_PARAMETER(GATES_LIST) on PIPE_ID_MAN, where the 
parameter value is equal to the existing value of GATES_LIST in the host's 
registry. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.3.1.2.2 



ANY GET PARAMETER 



5.3.1.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.2. 



RQ1 



A host shall reject an incorrectly formatted ANYGETPARAMETER command. 



RQ2 



A host shall reject an ANY_GET_PARAMETER command if the access right for the parameter does not 
allowed reading (i.e. is not RW or RO). 



RQ3 



A host shall not send an ANY_GET_PARAI\/IETER command if the access right for the parameter does 
not allowed reading (i.e. is not RW or RO). 



RQ4 



When a host receives a valid ANY_GET_PARAMETER command, it shall respond with ANY_OK with 
the value of the parameter. 



RQ5 



Whenever a host sends an ANY_GET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have exactly one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 



NOTE 1 : RQ3 is not tested, as it is a non-occurrence RQ. 

NOTE 2: RQ4 and RQ5 are not tested, as they are effectively tested in other clauses of the present document for 
each individual registry parameter. 



5.3.1.2.2.2 
5.3.1.2.2.2.1 



Test case 1 : ANY_GET_PARAMETER reception - invalid structure 
Test execution 



5.3.1.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 
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5.3.1.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY GET PARAMETER with no parameters on PIPE ID MAN. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


3 


HCS ^ HUT 


Send ANY_GET_PARAMETER containing parameters of length 2, with each 
byte containing the value of the GATES LIST identifier, on PIPE ID MAN. 




4 


HUT^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 



5.3.1.2.2.3 



5.3.1.2.2.3.1 



Test case 2: ANY_GET_PARAMETER reception - WO registry parameter 
Test execution 



Assignment of terms to entities referenced in SR4: Gjj-, of gate = GATE_X, registry parameter 
identifier = REG_PARAM. 

5.3.1.2.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_X) has been created to the gate with Gj^ = GATE_X, and is open. 



5.3.1.2.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE X. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ2 



5.3.1.2.3 



ANY OPEN PIPE 



5.3.1.2.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.3. 



RQ1 



A host shall reject an incorrectly formatted ANY_OPEN_PIPE command. 



RQ2 



When a host other than the host controller receives a valid ANY_OPEN_PIPE command on a closed 
pipe, it shall open the pipe and return ANY_OK with a parameter containing the "number of pipes already 
open on this gate before the execution of the command" 



RQ3 



When a host sends an ANY_OPEN_PIPE command, it shall contain no command parameters. 

When a host receives ANY_OK in response to an ANY_OPEN_PIPE command, it shall open the pipe. 



RQ4 



NOTE: In TS 102 622 [1], it is not clear whether ANY_OPEN_PIPE is valid over a pipe which is already open. 
This is therefore not listed as a conformance requirement. 



5.3.1.2.3.2 
5.3.1.2.3.2.1 



Test case 1 : ANY_OPEN_PIPE reception 
Test execution 



5.3.1.2.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 
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5.3.1.2.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_CLOSE_PIPE on PIPE^. 




2 


HUT^HCS 


Send ANY OK. 




3 


HCS ^ HUT 


Send ANY_OPEN_PIPE with parameter 'GO' on PIPE^. 




4 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


5 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and destination 
G|p = G|p of identity management gate. 




6 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


7 


HCS ^ HUT 


Send ANY_OPEN_PIPE on PIPE^. 




8 


HUT ^ HCS 


Send ANY OK with parameter '00'. 


RQ2 


9 


HCS -^ HUT 


Send ADIVI_NOTIFY_PIPE_CREATED on PIPE^, with source and destination 
G|p = G|p of identity management gate; designate the created pipe 
PIPE ID MAN. 




10 


HUT -> HCS 


Send ANY OK (parameters are not checked). 


RQ2 


11 


HCS -^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




12 


HUT ^ HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command. (See note). 


RQ2 


13 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




14 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


15 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and destination 

GID = GID of identity management gate; designate the created pipe 
PIPE ID MAN2. 




16 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


17 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN2. 




18 


HUT ^ HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command (see note). 


RQ2 


19 


HCS ^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN2. 




20 


HUT ^ HCS 


Send ANY OK. 




21 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN2. 




22 


HUT ^ HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command. 
NOTE: the same note as in step 12 applies. 


RQ2 


23 


HCS ^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN2. 




24 


HUT ^ HCS 


Send ANY OK. 




25 


HCS -^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN2. 




26 


HUT ^ HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command. (See note). 


RQ2 


27 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d = '01' and 
destination G|p = G|q of the loop back gate; designate the created pipe 
PIPE LOOP BACK. 




28 


HUT ^ HCS 


Send ANY OK. 




29 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




30 


HUT -» HCS 


Send ANY_OK with a parameter containing the number of pipes already open 
on this gate before the execution of the command (see note). 


RQ2 


NOTE: The test equipment must calculate the number of pipes already open on the gate before the execution 
of the command, taking into account any pipes which have been opened by the host. 
Example for step 12: if no pipes were opened to the host controller's identity management gate before 
the execution of the test procedure and no further pipes have been opened by the host, this value 
would be 'GO'. 



5.3.1.2.3.3 



Test case 2: ANY OPEN PIPE transmission 



5.3.1.2.3.3.1 



Test execution 



5.3.1.2.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 
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5.3.1.2.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




2 


HUT^HCS 


Send ANY OK. 




3 


User ^ HUT 


Trigger the host to open PIPE ID MAN. 




4 


HUT^HCS 


Send ANY OPEN PIPE on PIPE ID MAN. 


RQ3 


5 


HCS ^ HUT 


Send ANY OK. 




6 


HCS^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




7 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ4 



5.3.1.2.4 



ANY CLOSE PIPE 



5.3.1.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.4. 



R01 



A host shall reject an incorrectly formatted ANY_CLOSE_PIPE command. 



R02 



When a host receives a valid ANY_CLOSE_PIPE on an open pipe, it shall close the pipe and respond 
with ANYOK and no parameters. 



R03 



When a host sends an ANY_CLOSE_PIPE command, it shall contain no command parameters. 

When a host receives ANY_OK in response to an ANY_CLOSE_PIPE command, it shall close the pipe. 



R04 



5.3.1.2.4.2 
5.3.1.2.4.2.1 



Test case 1 : ANY_CLOSE_PIPE reception 
Test execution 



5.3.1 .2.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEj is open. 



5.3.1.2.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY_CLOSE_PIPE with parameter '00' on PIPE^. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ1 


3 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and 
destination G|p = G|q of identity management gate; designate the created 
pipe PIPE ID MAN. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ1 


5 


HCS^ HUT 


Send ANY_CLOSE_PIPE on PIPE^. 




6 


HUT -» HCS 


Send ANY OK with no parameters. 


RQ2 


7 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source and 
destination G|p = 0,0 of identity management gate. 




8 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ2 


9 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




10 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




11 


HCS ^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




12 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 




13 


HCS^ HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




14 


HUT ^ HCS 


Send ANY OK with no parameters. 


RQ2 


15 


HCS^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




16 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ2 
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5.3.1.2.4.3 



Test case 2: ANY CLOSE PIPE transmission 



5.3.1.2.4.3.1 



Test execution 



5.3.1.2.4.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 

5.3.1 .2.4.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HUT 


Trigger the host to close PIPE ID MAN. 




2 


HUT^HCS 


Send ANY CLOSE PIPE on PIPE ID MAN. 


R03 


3 


HCS^ HUT 


Send ANY OK. 




4 


HCS -> HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




5 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ4 



5.3.1.3 



Administration commands 



5.3.1.3.1 



ADM CREATE PIPE 



5.3.1 .3.1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.1. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.1 of the present 
document. 



5.3.1.3.2 



ADM NOTIFY PIPE CREATED 



5.3.1.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.2. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.1 of the present 
document. 



5.3.1.3.3 



ADM DELETE PIPE 



5.3.1.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.3. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5. 1 .2 of the present 
document. 



5.3.1.3.4 



ADM NOTIFY PIPE DELETED 



5.3.1.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.4. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5. 1 .2 of the present 
document. 
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ADM CLEAR ALL PIPE 



5.3.1.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.5. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5. 1 .3 of the present 
document. 



5.3.1.3.6 



ADM NOTIFY ALL PIPE CLEARED 



5.3.1.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.6. 

NOTE: All conformance requirements for the referenced clause are included in clause 5.5. 1 .3 of the present 
document. 



5.3.2 Responses 



5.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.2. 



RQ1 



A response shall be sent to all commands received even to those unknown to the receiving gate. 



RQ2 



Responses received out of order (i.e. if no command was sent previously) shall be discarded. 



RQ3 



For a received command which is defined in table 16 in TS 102 622 [1], hosts shall only return a 
response code which Is specified for that command in table 16 in TS 102 622 [1]. 



NOTE: Development of test cases for RQ3 is FFS. 

5.3.2.2 Test case 1 : response to unknown command 

5.3.2.2.1 Test execution 

5.3.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PlPEj is open. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 

5.3.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send command with an RFU instruction value on PIPE^. 




2 


HUT^HCS 


Send response (contents are not checked). 


RQ1 


3 


HCS^ HUT 


Send command with an RFU instruction value on PIPE ID MAN. 




4 


HUT ^ HCS 


Send response (contents are not checked). 


RQ1 
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5.3.2.3 



5.3.2.3.1 



Test case 2: responses received out of order, previous command sent by 
host controller 

Test execution 



5.3.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.3.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




2 


HUT^HCS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 




3 


HCS^ HUT 


Send response with ANY OK and no parameters on PIPE ID MAN. 




4 


HUT 


No message on PIPE ID MAN. 


R02 


5 


HCS-> HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




6 


HUT -» HCS 


Send response with ANY OK and same value of GATES LIST as in step 2. 


RQ2 



5.3.2.4 Test case 3: responses received out of order, previous command sent by 

host 

5.3.2.4.1 Test execution 

5.3.2.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.3.2.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ANY CLOSE PIPE on PIPE ID MAN. 




2 


HUT ^ HCS 


Send ANY OK. 




3 


User -» HUT 


Trigger the host to open PIPE ID MAN. 




4 


HUT ^ HCS 


Send ANY OPEN PIPE on PIPE ID MAN. 




5 


HCS^ HUT 


Send ANY OK on PIPE ID MAN. 




6 


HCS ^ HUT 


Send ANY E NOKonPIPE ID MAN. 




7 


HUT 


No message on PIPE ID MAN. 


R02 


8 


HCS -> HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




9 


HUT -» HCS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 


R02 



5.3.3 Events 

5.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.3. 



RQ1 



Unknown events received shall be discarded. 



RQ2 



When the host sends EVT_HCI_END_OF_OPERATION, it shall contain no parameters. 



RQ3 



For gates defined in TS 102 622 [1], hosts shall not use event values which are not allocated in 
TS102 622[1]. 



£75/ 



Release 7 



33 



ETSI TS 102 695-2 V7.2.0 (2010-10) 



NOTE 1: No RQs are specified for when the host should send EVT_HCI_END_OF_OPERATION, as the 
conditions for sending this event are internal to the host. 

NOTE 2: Development of test cases for RQ2 is FFS. 

NOTE 3: RQS is not tested, as it is a non-occurrence RQ. 

5.3.3.2 Test case 1 : reception of unknown events 

5.3.3.2.1 Test execution 

5.3.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 



5.3.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




2 


HUT^HCS 


Send response with ANY OK and value of GATES LIST on PIPE ID MAN. 




3 


HCS ^ HUT 


Send event with an RFU instruction value on PIPE ID MAN. 




4 


HCS^ HUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




5 


HUT ^ HCS 


Send response with ANY OK and same value of GATES LIST as in step 2. 


RQ1 



5.4 



GATES and subclauses 



5.4.1 GATES 

5.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7. 



|RQ1 [Gates shall support the commands and events specified for them in tables 18 and 19 of TS 102 622 [1]. | 

NOTE 1: In this clause, RQl is only tested for the management gates. Other clauses may test RQl for other gates as 
applicable. 

NOTE 2: ANY_GET_PARAMETER and ANY_SET_PARAMETER are not tested in this clause, as they are 
tested in the specific clauses for each gate for testing registry parameters. 

NOTE 3: ADM_NOTIFY_PIPE_CREATED, ADM_NOTIFY_PIPE_DELETED and 

ADM_NOTIFY_ALL_PIPE_CLEARED are not tested for the host administration gate, as they are tested 
in the specific clauses for each command. 

NOTE 4: EVT_POST_DATA is not tested for the loop back gate, as it is tested in the clause 5.5.5. 

NOTE 5: EVT_HOT_PLUG is not tested for the host administration gate, as the reaction of the host is not specified 
inTS 102 622 [1]. 
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5.4.1 .2 Test case 1 : command and event support for link management gate 

5.4.1.2.1 Test execution 

5.4.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEq i^ open. 



5.4.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -» HUT 


Send ANY_CLOSE_PIPE on PIPEg. 




2 


HUT^HCS 


Send ANY OK (parameters are not checked). 


RQ1 


3 


HCS ^ HUT 


Send ANY_OPEN_PIPE on PIPEg. 




4 


HUT -» HCS 


Send ANY OK (parameters are not checked). 


RQ1 



5.4.1 .3 Test case 2: command and event support for management gates except link 

management gate 



5.4.1.3.1 



Test execution 



The test procedure shall be executed once for each of following parameters, indicating the pipe to be used in the test 
procedure: 

• PIPEj; 

• a pipe which has been created from the host controller's identity management gate to the host's identity 
management; 

• a pipe which has been created from gate with Gjq = '01' on the host controller to the host's loop back gate. 

5.4.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• The pipe indicated in the test execution clause is open. 



5.4.1.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY CLOSE PIPE on the pipe indicated in the test execution clause. 




2 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ1 


3 


HCS^ HUT 


Send ANY OPEN PIPE on the pipe indicated in the test execution clause. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ1 
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5.4.2 Management gates 
5.4.2.1 Administration gates 

5.4.2.1 .1 Host controller administration gate 



5.4.2.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.1.1. 



RQ1 



The host shall only set values of SESSIONJDENTITY with length 8 bytes. 



RQ2 



The session identity shall be modified by the host whenever a modification of the configuration is 
performed by the host. 



RQ3 



The default value of the session identity shall never be written by a host. 



RQ4 



The session identity shall use random values. 



RQ5 



The host shall adhere to the access condition of RO for MAX PIPE. 



RQ6 



The host shall only set values of WHITELIST containing valid host identifiers (including proprietary host 
identifiers but excluding RFU host identifiers) as specified in table 1 in TS 102 622 [1], and not containing 

the host controller's host identifier and the host's own host identifier; an empty array is allowed. 

The host shall adhere to the access condition of RO for HOST LIST. 



R07 



NOTE 1: RQ2 is not tested in this clause. It is tested in the context of HCI session initialization in clause 5.5.4. As 
other circumstances in which the host may modify the configuration are not evident, it is not tested 
further in this clause. 

NOTE 2: RQ5 and RQ7 are not tested, as they are non-occurrence RQs. 
5.4.2.1 .1 .2 Test case 1 : SESSIONJDENTITY 

5.4.2.1.1.2.1 Test execution 

Run this test procedure in full power mode only. 

5.4.2.1.1.2.2 Initial conditions 
• The host is not powered up. 

5.4.2.1.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^ ^ HCS 


Perform HCI session initialization. 




3 


HUT^ HCS 


Send ANY_SET_PARAMETER(SESSION_IDENTITY) on PIPE^. 
Check value is 8 bytes long, and is different from the default value. 


RQ1, 
RQS 


4 


HCS ^ HUT 


Send ANY OK. 




5 




Execute steps 7 to 12 ten times. 




6 


HCS -^ HUT 


Power down host. 




7 


HCS -^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




8 


HUT^ ^ HCS 


Perform HCI session initialization. 




9 


HUT ^ HCS 


Send ANY_SET_PARAMETER(SESSION_IDENTITY) on PIPE^. 

Check value is 8 bytes long, is different from the default value, and is 
different from any value previously sent by the host in the test procedure. 


RQ1, 
RQS, 
RQ4 


10 


HCS ^ HUT 


Send ANY OK. 
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Testcase2:WHITELIST 



Test execution 



5.4.2.1.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.4.2.1.1.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -» HUT 


Trigger the host to write its value of WHITELIST into the registry of the host 
controller's administration gate. 




2 


HUT^HCS 


Send ANY_SET_PARAMETER(WHITELIST) on PIPE^. 


RQ6 


3 


HCS ^ HUT 


Send ANY OK. 





5.4.2.1.2 



Host administration gate 



5.4.2.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.1.2 and 4.5. 



RQ1 



4.5 



Registry parameters which are In the range of '00' to 'EF' but which are not allocated In TS 1 02 622 [1 ] 
shall not be present In the registry. 



NOTE: Development of test cases for RQl is FFS. 

5.4.2.2 Link management gate 

5.4.2.2.1 Host controller link management gate 

5.4.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.2.1. 



I R01 |The host shall only set values of REC_ERROR with length 2 bytes. 



5.4.2.2.1.2 



5.4.2.2.1.2.1 



Test case 1 : REC ERROR 



Test execution 



5.4.2.2.1 .2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEq is open. 



5.4.2.2.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HUT 


Trigger the host to write a value of REC_ERROR Into the registry of the host 
controller's link management gate In order to restart an error rate measure. 




2 


HUT ^ HCS 


Send ANY_SET_PARAMETER(REC_ERROR) on PiPEg. 


RQ1 


3 


HCS ^ HUT 


Send ANY OK. 
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5.4.2.2.2 



Host link management gate 



5.4.2.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.2.1 and 4.5. 



RQ1 



4.5 



Registry parameters whicli are in tlie range of '00' to 'EF' but wliicli are not allocated in TS 1 02 622 [1 ] 
shall not be present in the registry. 



RQ2 



7.1.2.1 



The host shall use a default value for REG ERROR of '0000'. 



RQ3 



7.1.2.1 



The host shall apply the access condition of RW to REC_ERROR. 



RQ4 



7.1.2.1 



The host shall only accept values of REC_ERROR of length 2 bytes. 



NOTE: Development of test cases for RQl is FFS. 
5.4.2.2.2.2 Test case 1 : REG ERROR 



5.4.2.2.2.2.1 



Test execution 



5.4.2.2.2.2.2 Initial conditions 

• The last value of REC_ERROR in the host's registry for PIPEq is not '0000'. 

• The interface is powered down. 



5.4.2.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HGS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^ ^ 
HGS 


Perform HGI session initialization, up to and including setting new value of 
SESSION IDENTITY. 




3 


HGS 


Wait until the HGI interface is idle; i.e. no further communication is expected. 




4 


HGS ^ HUT 


Send ANY_GET_PARAMETER(REG_ERROR) on PIPEg. 




5 


HUT ^ HGS 


Send ANY_OK with parameter value '0000' (see note). 


R02, 
RQ3 


6 


HGS ^ HUT 


Send ANY_SET_PARAMETER(REG_ERROR, '0000') on PIPEq. 




7 


HUT ^ HGS 


Send ANY OK. 


RQ3 


8 


HGS ^ HUT 


Send ANY_SET_PARAMETER(REG_ERROR, '000000') on PIPEq. 




9 


HUT ^ HGS 


Send response containing an allowed error response code for the command. 


RQ4 


NOTE: This assumes that the HCI session initialization procedure has not resulted in any errors at the data 
link layer which would result in the incrementing of REG ERROR. 



5.4.2.3 Identity management gate 

5.4.2.3.1 Local registry 



5.4.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.3 and 4.5. 

NOTE 1: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
local registry. The requirements for the remote registry are contained in clause 5.4.2.3.2. 



R01 


4.5 


Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 


R02 


7.1.3 


The registry of the identity management gate shall be persistent. 


R03 


7.1.3 


This gate shall be provided by all hosts and the host controller. 


R04 


7.1.3 


If present in the host, the host shall use a value for VERSION SW of length 3 bytes. 


RQ5 


7.1.3 


If present in the host, the host shall apply the access condition of RO to VERSION_SW. 
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RQ6 


7.1.3 


If present in the host, the host shall use a value for VERSION HARD of length 3 bytes. 


RQ7 


7.1.3 


If present in the host, the host shall apply the access condition of RO to VERSION HARD. 


RQ8 


7.1.3 


If present in the host, the host shall use a value for VERSION_NAME of maximum length 20 bytes with 
UTF8 coding. 


RQ9 


7.1.3 


If present in the host, the host shall apply the access condition of RO to VERSION NAIVIE. 


RQ10 


7.1.3 


If present in the host, the host shall use a value for MODEL ID of length 1 byte. 


RQ11 


7.1.3 


If present in the host, the host shall apply the access condition of RO to MODEL ID. 


RQ12 


7.1.3 


If present in the host, the host shall apply the access condition of RO to HCI VERSION. 


RQ13 


7.1.3 


The host shall use a value for GATES_LIST containing the list of all gates that accept dynamic pipes as 
an array of gate identifiers. 


RQ14 


7.1.3 


The host shall apply the access condition of RO to GATES LIST. 


RQ15 


7.1.3 


A host according to the present document shall set the HCI VERSION parameter if provided to '01 '. 



NOTE 2: Development of test cases for RQl is FFS. 

NOTE 3: RQ2 is not tested within this clause, as the registry contains no writeable parameters which can be used to 
test the persistence of the registry. 

NOTE 4: RQ3 is also covered in clause 4.3 of TS 102 622 [1], covered by clause 5.1.3 of the present document. 
This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.1.3. 



5.4.2.3.1.2 



Test case 1 : registry parameters 



5.4.2.3.1.2.1 



Test execution 



The test procedure shall be executed for each of the parameters in the following table: 



Registry parameter 

(designated 
REG PARAM) 


Presence 


Expected value 

(designated VALUE) 


Value to be used in 
ANY SET PARAMETER 

(designated VALUE SET) 


RQ to be 

checked in 

steps 2 and 6 


RQ to be 

checked in 

step 4 


VERSION SW 





V VERSION SW 


'01 01 01' 


R04 


R05 


VERSION HARD 





V VERSION HARD 


'01 01 01' 


RQ6 


RQ7 


VERSION NAME 





V VERSION NAME 


'56 65 6E 64 6F 72' 


ROB 


RQ9 


MODEL ID 





V MODEL ID 


'01' 


RO10 


R011 


HCI VERSION 





V HCI VERSION 


'01' 


R015 


R012 


GATES LIST 


M 


V GATES LIST 


'04 05' 


RQl 3 


RQl 4 



5.4.2.3.1 .2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host's identity management gate, and is open. 
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5.4.2.3.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE ID MAN. 




2 


HUT^ HCS 


If REG_PARAM is supported by the device under test as indicated in 

table 4.3, send ANY_OK with parameter value equal to VALUE. 

If REG_PARAIVI is not supported by the device under test as indicated in 

table 4.3, send response containing an allowed error response code for the 

command. 


See test 

execution 

clause 


3 


HCS ^ HUT 


Send ANY SET PARAMETER(REG PARAM, VALUE SET) on 
PIPE ID MAN. 




4 


HUT^ HCS 


Send response containing an allowed error response code for the 
command. 


See test 

execution 

clause 


5 


HCS ^ HUT 


Send ANY GET PARAMETER(REG PARAM) on PIPE ID MAN. 




6 


HUT ^ HCS 


If REG_PARAM is supported by the device under test as indicated in 

table 4.3, send ANY_OK with parameter value equal to VALUE. 

If REG_PARAM is not supported by the device under test as indicated in 

table 4.3, send response containing an allowed error response code for the 

command. 


See test 

execution 

clause 



5.4.2.3.2 



Remote registry 



5.4.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.3. 

NOTE 1: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
remote registry. The requirements for the local registry are contained in clause 5.4.2.3.1. 



RQ1 



The host shall adhere to the access condition of RO for VERSION SW in the host controller. 



RQ2 



The host shall adhere to the access condition of RO for VERSION HARD in the host controller. 



RQ3 



The host shall adhere to the access condition of RO for VERSION NAME in the host controller. 



RQ4 



The host shall adhere to the access condition of RO for MODEL ID in the host controller. 



RQ5 



The host shall adhere to the access condition of RO for HCI VERSION in the host controller. 



RQ6 



The host shall adhere to the access condition of RO for GATES LIST in the host controller. 



RQ7 



Every host shall manage backward compatibility with previous HCI versions and use only commands and 
parameters defined in the specification having the lower HCI version number between of the 2 hosts 
involved in a transaction. 



RQ8 



A host connected to a host with higher HCI version number shall operate according to its own version. 



NOTE 2: RQl, RQ2, RQ3, RQ4, RQ5 and RQ6 are not tested, as they are non-occurrence RQs. 

NOTE 3: In the current version of the present document, there are no previous HCI versions. RQ7 is therefore not 
tested in the current version of the present document. 

NOTE 4: Development of test cases for RQS is PES. 

5.4.2.4 Loop back gate 

5.4.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.4 and 4.5. 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] shall 
not be present in the registry. 



RQl 



4.5 



NOTE: Development of test cases for RQl is FES. 
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5.4.3 Generic gates 

Reference: TS 102 622 [1], clause 7.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.5 HCI procedures 

5.5.1 Pipe management 

5.5.1.1 Pipe creation 

5.5.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.1, 6.1.3.1 and 6.1.3.2. 



RQ1 


6.1.3.1 


When a host sends an ADM_CREATE_PIPE command, the command parameters shall be 3 bytes long, 
and contain valid Gi^s and H|p. 


RQ2 


6.1.3.2 


When a host receives an ADIVI_NOTIFY_PIPE_CREATED command, it shall respond with ANY_OK with 
no parameters if it accepts the pipe. 


RQ3 


6.1.3.2 


If a host receives an ADM_NOTIFY_PIPE_CREATED command containing a destination H|p which is 
not the H|p of the host, it shall reject the pipe creation. 


RQ4 


8.1.1 


If host B does not accept the creation of the pipe, it shall respond to ADI\/l_NOTIFY_PIPE_CREATED 
with an appropriate response code. 



5.5.1.1.2 



5.5.1.1.2.1 



Test case 1 : ADM CREATE PIPE 



Test execution 



5.5.1.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.1.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HUT 


Trigger the host to create a pipe. 




2 


HUT ^ HCS 


Send ADM_CREATE_PIPE on PIPE^; designate the created pipe PIPE_ID_IVIAN. 


R01 


3 


HCS ^ HUT 


Send ANY OK with valid response parameters. 




4 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




5 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


R01 



5.5.1.1.3 



5.5.1.1.3.1 



Test case 2: ADM NOTIFY PIPE CREATED from host controller 



Test execution 



5.5.1.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|o '01' and 
destination G|p of the loop back gate; designate the create pipe 
PIPE LOOP BACK. 




2 


HUT^HCS 


Send ANY OK with no parameters. 


RQ2 


3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




4 


HUT->HCS 


Send ANY OK (parameters are not checked). 


RQ2 


5 


HCS-^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




6 


HUT ^ HCS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


RQ2 



5.5.1.1.4 



5.5.1.1.4.1 



Test case 3: ADM NOTIFY PIPE CREATED from other host 



Test execution 



5.5.1.1.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.1.1.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^ with source H|d equal to a 
value in the WHITELIST of the host, source G^q = '01 ' and destination G|q = 
G|Q of the loop back gate; designate the created pipe PIPE_LOOP_BACK. 




2 


HUT ^ HCS 


Send ANY OK with no parameters. 


RQ2 


3 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




4 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ2 


5 


HCS^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




6 


HUT ^ HCS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


RQ2 



5.5.1 .1 .5 Test case 4: ADM_NOTIFY_PIPE_CREATED with incorrect destination Hid 

5.5.1.1.5.1 Test execution 

5.5.1.1.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.1.1.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^ with destination Hi^ equal 
to a proprietary H|p according to table 1 of TS 102 622 [1] but which is not 
equal to the H|q of the host, with source G|q = '01 ' and destination G|d = G|d 
of the loop back gate. 




2 


HUT ^ HCS 


Send response containing an allowed error response code for the command. 


RQ3 
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Test case 5: unsuccessful ADM NOTIFY PIPE CREATED 



5.5.1.1.6.1 Test execution 

Assignment of terms to entities referenced in SR5: Gj^ of gate = GATE_UNSUPPORTED. 

5.5.1.1.6.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.1.1.6.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d = '01' and 
destination G|o equal to GATE_UNSUPPORTED. 




2 


HUT^HCS 


Send response containing an allowed error response code for the command. 


RQ4 



5.5.1.2 



Pipe deletion 



5.5.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.2, 6.1.3.3 and 6.1.3.4. 



RQ1 


6.1.3.3 


When a host sends an ADM DELETE PIPE command, the command parameters shall be 1 byte long. 


RQ2 


6.1.3.3 


When a host sends an ADM_DELETE_PIPE command, the host that requested the deletion of the pipe 
shall be the source host or destination host. 


RQ3 


6.1.3.4 


When a host receives a valid ADI\/l_NOTIFY_PIPE_DELETED command, it shall respond with ANY_OK 
with no parameters. 



NOTE: RQ2 is not tested, as it is a non-occurrence RQ. 

5.5.1 .2.2 Test case 1 : sending ADM_DELETE_PIPE 

5.5.1.2.2.1 Test execution 

5.5.1.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE[ is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 
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5.5.1.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ HUT 


Trigger the host to send ADM_DELETE_PIPE on PIPE^ to delete 
PIPE LOOP BACK. 




2 


HUT^HCS 


Send ADM_DELETE_PIPE on PIPE^, with parameter value of length 1 and 
equal to PIPE LOOP BACK. 


RQ1 


3 


HCS ^ HUT 


Send ANY OK. 




4 


HCS -^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




5 


HUT ^ HCS 


No messages on PIPE LOOP BACK. 


RQ1 


6 


HCS -» HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




7 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


RQ1 



5.5.1 .2.3 Test case 2: receiving ADM_NOTIFY_PIPE_DELETED 

5.5.1.2.3.1 Test execution 

5.5.1.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE[ is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 

5.5.1 .2.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS^ HUT 


Send ADM_ NOTIFY_PIPE_DELETED on PIPE^, with parameter value of 
length 1 and equal to PIPE LOOP BACK. 




2 


HUT ^ HCS 


Send ANY OK. 


RQ3 


3 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




4 


HUT ^ HCS 


No messages on PIPE LOOP BACK. 


RQ3 


5 


HCS^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




6 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


RQ3 



5.5.1.3 



Clear all Pipes 



5.5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.3,6.1.3.5 and 6.1.3.6. 



R01 


6.1.3.5 


When the host sends an ADIVI_CLEAR_ALL_PIPE command and the data link layer specified in 
TS 102 613 [2] is used, the command parameters shall be two bytes long. 


R02 


6.1.3.5 


When the data link layer specified in TS 102 613 [2] is used, the identity reference data in the 
ADM CLEAR ALL PIPE command shall contain random elements. 


R03 


6.1.3.5 


When the host receives ANY_OK in response to an ADM_CLEAR_ALL_PIPE command, it shall 
consider that all dynamic pipes connected to it are deleted, all static pipes connected to it are closed, 
and all registry values related to static pipes connected to it are set to their default values. 


R04 


6.1.3.6 


When the host receives a valid ADIVI_NOTIFY_ALL_PIPE_CLEARED command, and the requesting 
host is not the host controller, the host shall consider all dynamic pipes between the host and the 
requesting host to be deleted. 


RQ5 


6.1.3.6 


When the host receives a valid ADIVI_NOTIFY_ALL_PIPE_CLEARED command, and the requesting 
host is the host controller, the host shall consider all dynamic pipes between the host controller and the 
host to be deleted, and all static pipes between the host and the host controller to be closed. 


R06 


6.1.3.6 


The host shall respond to an ADIVI_NOTIFY_ALL_PIPE_CLEARED command with an ANY_OK without 
parameters. 
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NOTE: Development of test cases for RQ4, RQ5 and RQ6 is FFS. 

5.5.1 .3.2 Test case 1 : ADM_CLEAR_ALL_PIPE for data link layer specified in TS 102 613 

5.5.1.3.2.1 Test execution 

Run this test procedure in full power mode only. 

5.5.1.3.2.2 Initial conditions 
• The host is not powered up. 

5.5.1.3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -> HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^HCS 


Send ADM_CLEAR_ALL_PIPE on PIPE^, with a parameter value of length 
2 bytes (see note). 


RQ1 


3 


HCS ^ HUT 


Send ANY OK. 




4 


HCS 


Wait for HCI session initialization to be completed, and for the HCI interface to 
be idle; i.e. no further communication is expected. 




5 




Execute steps 7 to 11 ten times. 




6 


HCS ^ HUT 


Power down host. 




7 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




8 


HUT ^ HCS 


Send ADM_CLEAR_ALL_PIPE on PIPE^, with a parameter value of length 

2 bytes, and with a value different from any value previously sent by the host 
in the test procedure (see note). 


RQ2 


9 


HCS ^ HUT 


Send ANY OK. 




NOTE: Other commands may be sent prior to the ADM CLEAR ALL PIPE command. 



5.5.1 .3.3 Test case 2: ADM_CLEAR_ALL_PIPE - static pipes, dynamic pipes to host 

controller 

5.5.1.3.3.1 Test execution 

Run this test procedure in full power mode only. 

5.5.1.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 
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5.5.1.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS -^ HUT 


Power down host. 




2 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




3 


HUT ^ HCS 


Send ADIVI_CLEAR_ALL_PIPE on PIPE^; parameter value is not checked 
(see note 1). 




4 


HCS ^ HUT 


Send ANY OK. 




5 


HUT ^ HCS 


Send ANY_OPEN_PIPE on PIPE^. 


RQ3 


6 


HCS ^ HUT 


Send ANY OK. 




7 


HCS 


See note 2. 




8 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




9 


HUT ^ HCS 


No messages on PIPE LOOP BACK. 


RQ3 


10 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




11 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


RQ3 


NOTE 1 : Other commands may be sent prior to the ADM_CLEAR_ALL_PIPE command. 

NOTE 2: The host controller simulator shall not use PIPE LOOP BACK for any subsequent pipe creation. 



5.5.1 .3.4 Test case 3: ADM_CLEAR_ALL_PIPE - dynamic pipes to other host 

5.5.1.3.4.1 Test execution 

Run this test procedure in full power mode only. 

5.5.1.3.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 

• A pipe (PIPE_LOOP_BACK) has been created from gate '01' on a host whose Hjq is in the WHITELIST of 
the host to the host's loop back gate, and is open. 



5.5.1.3.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power down host. 




2 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




3 


HUT ^ HCS 


Send ADIVI_CLEAR_ALL_PIPE on PIPE^; parameter value is not checked 
(see note 1). 




4 


HCS ^ HUT 


Send ANY OK. 




5 


HCS 


See note 2. 




6 


HCS ^ HUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




7 


HUT ^ HCS 


No messages on PIPE LOOP BACK. 


R03 


8 


HCS ^ HUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




9 


HUT ^ HCS 


Send no response, or a response containing an allowed error response code 
for the command. 


R03 


NOTE 1 : Other commands may be sent prior to the ADM_CLEAR_ALL_PIPE command. 

NOTE 2: The host controller simulator shall not use PIPE_LOOP_BACK for any subsequent pipe creation. 
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5.5.1 .3.5 Test case 4: ADM_CLEAR_ALL_PIPE - registry parameters 

5.5.1.3.5.1 Test execution 

5.5.1.3.5.2 Initial conditions 

• REC_ERROR in the registry of the host for PIPEq has a value which is different from the default value. 

• The host is not powered up. 



5.5.1.3.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT^HCS 


Send ADM_CLEAR_ALL_PIPE on PIPE^; parameter value is not checked 
(see note 1). 




3 


HCS ^ HUT 


Send ANY OK. 




4 


HCS ^ HUT 


Send ANY_OPEN_PIPE on PIPEg. 




5 


HUT -> HCS 


Send ANY OK (parameters are not checked). 




6 


HCS ^ HUT 


Send ANY_GET_PARAMETER(REC_ERROR) on PiPEg. 




7 


HUT ^ HCS 


Send ANY OK with parameter value '0000' (see note 2). 


R03 


NOTE 1 : Other commands may be sent prior to the ADIVI_CLEAR_ALL_PIPE command. 
NOTE 2: This assumes that the HCI session initialization procedure has not resulted in any errors at the data 
link layer which would result in the incrementing of REG ERROR. 



5.5.2 Registry access 

Reference: TS 102 622 [1], clause 8.2. 
There are no new conformance requirements for the UICC for the referenced clause. 

5.5.3 Host and Gate discovery 

Reference: TS 102 622 [1], clause 8.3. 
There are no conformance requirements for the UICC for the referenced clause. 

5.5.4 Session initialization 
5.5.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.4. 



RQ1 



The Host shall perform session initialization only if no contactless transaction is pending at startup 
(e.g. after power up in full-power mode as defined in TS 102 613 [2]). 



RQ2 



If the data link layer specified in TS 102 613 [2] is being used, then after power up in full-power mode, 
the host shall perform session initialization. 



RQ3 



If the returned value of SESSION_IDENTITY equals the previous value stored in the host, the host shall 
stop the session initialization procedure. 



RQ4 



If the returned value of SESSION_IDENTITY does not equal the previous value stored in the host, the 
host needs to reinitialize and it requests the host controller to clear all pipes. 



R05 



In the context of R04, after performing any further initializations, the host generates a new session 
identity and stores its value and stores it in the host controller registry. 



NOTE: RQl is not tested in this clause, as the only circumstances where no contactless transaction is pending at 
startup which are defined after power up in full-power mode as defined in TS 102 613 [2], which is dealt 
with in RQ2. 
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Test case 1 : SESSIONJDENTITY not changed 



5.5.4.2.1 Test execution 

Run this test procedure in full power mode only. 

5.5.4.2.2 Initial conditions 

• The host is not powered up. 



5.5.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host. 




2 


HUT^HCS 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE^ (see note). 




3 


HCS ^ HUT 


Send ANY OK with SESSION IDENTITY. 




4 


HUT-» ^ HCS 


Wait for any HCI session initialization to complete. 




5 


HCS ^ HUT 


Power down host. 




6 


HCS ^ HUT 


Power up host. 




7 


HUT ^ HCS 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE^ (see note). 


RQ2 


8 


HCS -> HUT 


Send ANY OK with the same value of SESSION IDENTITY as in step 3. 




9 


HUT ^ HCS 


Do not send ADM CLEAR ALL PIPE or 

ANY SET PARAMETER(SESSION IDENTITY). 


RQ3 


NOTE: Other commands may be sent prior to the ANYGETPARAMETER command. 



5.5.4.3 



Test case 2: SESSIONJDENTITY changed 



5.5.4.3.1 Test execution 

Run this test procedure in full power mode only. 

5.5.4.3.2 Initial conditions 

• The host is not powered up. 



5.5.4.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Power up host; behave as if lower layer identity check has failed (i.e. enter 
inhibited state). 




2 


HUT -^ HCS 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE^ (see note 1). 


R02 


3 


HCS ^ HUT 


Send ANY OK with the value of SESSION IDENTITY. 




4 


HUT ^ HCS 


Send ADM_CLEAR_ALL_PIPE on PIPE^; parameter value is not checked 
(see note 2) 


RQ4 


5 


HCS ^ HUT 


Send ANY OK. 




6 


HUT ^ HCS 


Send ANY_SET_PARAMETER(SESSION_IDENTITY) on PIPE^ with a 
different value from that previously used by the host (see note 1). 


R05 


7 


HCS ^ HUT 


Send ANY OK. 




NOTE 1 : Other commands may be sent prior to the ANY_GET_PARAIVIETER command. 
NOTE 2: other commands may be sent prior to the ADM CLEAR ALL PIPE command. 
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5.5.5 Loop back testing 

5.5.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.5. 



RQ1 



A host shall accept the creation of a pipe to its loop back gate from any gate in another host. 



RQ2 



When a host receives the event EVT_POST_DATA on a pipe connected to its loop back gate, it shall 
send back the event EVT POST DATA with same data as received in the received EVT POST DATA. 



R03 



The loopback gate shall support at least all messages with size up to 250 bytes. 



5.5.5.2 



Test case 1 : pipe creation from host controller 



5.5.5.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Source Gj^ values of: '00', '03', '05', '10', 'AA', 'FF. 

5.5.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source G|d as 
specified and destination G|p = G|p of loop back gate. 




2 


HUT^HCS 


Send ANY OK (parameters are not checked). 


RQ1 



5.5.5.3 



Test case 2: pipe creation from another host 



5.5.5.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Source Gj^ values of: '00', '03', '05', '10', 'AA', 'FF'. 

5.5.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPEj is open. 



5.5.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send ADM_NOTIFY_PIPE_CREATED on PIPE^, with source H^^ equal to 
the H|Q contained in the host's WHITELIST, source G|q as specified and 
destination G|q = G|d of loop back gate. 




2 


HUT ^ HCS 


Send ANY OK (parameters are not checked). 


RQ1 
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5.5.5.4 Test case 3: processing of EVT_POST_DATA 

5.5.5.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• EVT_POST_DATA data sizes of: 1 byte, 100 bytes, 250 bytes. 

5.5.5.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_LOOP_BACK) has been created to the host's loop back gate, and is open. 

5.5.5.4.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HCS ^ HUT 


Send EVT_POST_DATA on PIPE_LOOP_BACK containing data of the 
specified size. 




2 


HUT^HCS 


Send EVT_POST_DATA on PIPE_LOOP_BACK containing the same data 
as in step 1 . 


RQ2, 
RQ3 



5.6 



Contactless card emulation 



5.6.1 Overview 

5.6.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.1. 



RQ1 



For each card RF gate it wants to use, the host has one card application gate. 



RQ2 



For the contactless platform for card emulation mode the pipes to card RF gates shall be created, 
opened, closed and deleted by the host. 



RQ3 



The host shall not create more than one pipe to each RF gate. 



NOTE: Development of test cases for above listed RQs is FES. 

5.6.2 Void 

Reference: TS 102 622 [1], clause 9.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3 Gates 
5.6.3.1 Void 

Reference: TS 102 622 [1], clause 9.3.1. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.6.3.2 Identity management gate 
5.6.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.2. 
I RQ1 |The host shall adhere to the access condition of RO for LOW_POWER_SUPPORT. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.6.3.3 Card RF gates 

5.6.3.3.1 Overview 

Reference: TS 102 622 [1], clause 9.3.3.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.3.2 Commands 

5.6.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.3.3 Events and subclauses 

5.6.3.3.3.1 Events 

5.6.3.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.3. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.3.3.2 EVT_SEND_DATA 
Reference: TS 102 622 [1], clause 9.3.3.3.1. 

There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.3.4 Registry and subclauses 

5.6.3.3.4.1 Registry 

5.6.3.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.6.3.3.4.2 



RF technology type A 



5.6.3.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.1. 



RQ1 



The host shall only set values of MODE of 'FF' and '02'. 



RQ2 



The host shall only set values of UID_REG with length 0, 4, 7 or 10. 



RQ3 



The host shall adhere to the access condition of WO for DID REG. 



R04 



The host shall only set values of CID_SUPPORT with value '00' or '01'. 



R05 



The host shall adhere to the access condition of RO for CLT SUPPORT. 



RQ6 



The host shall only set values of DATARATE_IVIAX which codes maximum divisor supported with coding 
as specified in TS 102 622 [1]. 



NOTE 1: The conformance to ISO/IEC 14443-3 [4] and ISO/IEC 14443-4 [5] of the values written by the host is 
out of scope of the present document. 

NOTE 2: Development of test cases for above listed RQs is FFS. 



5.6.3.3.4.3 



RF technology type B 



5.6.3.3.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.2. 



RQ1 



The host shall only set values of IVIODE of 'FF' and '02'. 



RQ2 



The host shall only set values of PUPI_REG with length or 4. 



RQS 



The host shall adhere to the access condition of WO for PUPI REG. 



RQ4 



The host shall only set values of ATQB with length 4. 



RQS 



The host shall only set values of DATARATE_MAX which codes maximum bit rates supported with 
coding as specified in TS 102 622 [1]. 



NOTE 1: The conformance to ISO/lEC 14443-3 [4] and ISO/lEC 14443-4 [5] of the values written by the host is 
out of scope of the present document. 

NOTE 2: Development of test cases for above listed RQs is FFS. 

5.6.3.3.4.4 RF technology type B' 

5.6.3.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.3. 
NOTE: Since this technology is not publicly disclosed, no conformance requirements have been established. 
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5.6.3.3.4.5 RF technology Type F (ISO18092 212 kbps/424 kbps card emulation only) 

5.6.3.3.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.4. 



RQ1 



The host shall only set values of MODE of 'FF' and '02'. 



RQ2 



The host shall adhere to the access condition of RO for SPEED CAP. 



RQ3 



The host shall adhere to the access condition of RO for CLT SUPPORT. 



NOTE: Development of test cases for above listed RQs is EPS. 

5.6.3.4 Card application gates 

5.6.3.4.1 Overview 

Reference: TS 102 622 [1], clause 9.3.4.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.4.2 Commands 

5.6.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.3.4.3 Events and subclauses 

5.6.3.4.3.1 Events 

5.6.3.4.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3. 



|R01 [Each card application gate shall support all events as listed. 



NOTE: Development of test cases for above listed RQs is EES. 

5.6.3.4.3.2 EVT_FIELD_ON 

5.6.3.4.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.1. 

There are no conformance requirements for the UICC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 

5.6.3.4.3.3 EVT_CARD_DEACTIVATED 

5.6.3.4.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.2. 

There are no conformance requirements for the UICC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 
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5.6.3.4.3.4 EVT_CARD_ACTIVATED 

5.6.3.4.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.3. 

There are no conformance requirements for the UlCC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 

5.6.3.4.3.5 EVT_FIELD_OFF 

5.6.3.4.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.4. 

There are no conformance requirements for the UlCC for the referenced clause (usage of this event is described in 
clause 9.4 of TS 102 622 [1]). 

5.6.3.4.3.6 EVT_SEND_DATA 

5.6.3.4.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.5. 
|RQ1 |0n receiving EVT_SEND_DATA the host shall interpret the last parameter byte as RF error indicator. | 



NOTE: Development of test cases for above listed RQs is FFS. 

5.6.3.4.4 Registry 

5.6.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.4. 



RQ1 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.6.4 Procedures 

5.6.4.1 Use of contactless card application 

5.6.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.1. 



RQ1 



In the context of a valid contactless card application sequence as specified in TS 102 622 [1], the host 
shall reply to received C-APDUs contained in EVT_SEND_DATAs by sending the R-APDUs contained in 
EVT_SEND_DATAs to the card RF gate. 



RQ2 



The host shall accept an EVT_FIELD_OFF which is received at any time during the sequence. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.6.4.2 Non ISO/IEC 1 4443-4 type A 

5.6.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.2. 



RQ1 



In the context of a valid contactless card application sequence as specified in TS 102 622 [1], the host 
shall perform communications using the CLT mode as defined in TS 102 613 [2], 



RQ2 



The host shall accept an EVT_FIELD_OFF which is received at any time during the sequence. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.6.4.3 Type B' RF technology 
5.6.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.3. 

NOTE: Since this technology is not publicly disclosed, no conformance requirements have been established. 

5.6.4.4 Type F RF technology 
5.6.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.4. 



RQ1 



In the context of a valid contactless card application sequence as specified in TS 102 622 [1], and In 
case SWP as defined in TS 102 613 [2] is used as a data link layer, the initialization data exchange is 
performed using CLT as defined in TS 102 613 [2] 



RQ2 



In the context of a valid contactless card application sequence as specified in TS 102 622 [1], the host 
shall reply to received ISO/IEC 18092 [3] 212 kbps/424 kbps frames contained in EVT_SEND_DATAs by 
sending the ISO/IEC 18092 [3] 212 kbps/424 kbps frames contained in EVT_SEND_DATAs to the card 
RF gate. 



RQ3 



The host shall accept an EVT_FIELD_OFF which is received at any time during the sequence. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.6.4.5 Update RF technology settings 
5.6.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.5. 
There are no conformance requirements for the UICC for the referenced clause. 

5.6.4.6 Identity check 

5.6.4.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.6. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.7 



Contactless reader 



5.7.1 



Overview 



5.7.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.1. 



RQ1 



For each reader RF gate it wants to use, the host has one reader application gate. 



RQ2 



The host shall not create more than one pipe to each reader RF gate. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.2 Reader RF gates 

5.7.2.1 Overview 

Reference: TS 102 622 [1], clause 10.2.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.2.2 Command 
5.7.2.2.1 WR XCHG DATA 



5.7.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.2.1. 



RQ1 



The host shall have at least one byte in parameter of WR_XCHG_DATA. 



RQ2 



In the CTR field of WR XCHG DATA, bit b8 to b6 shall set to 0. 



RQS 



In the CTR field of WR_XGHG_DATA, if bit b5 is set to one, the host shall use timeout value 
between and 14. 



RQ4 



On receiving value '00' of RF error indicator, the host shall interpret the received data having no 
error. 



R05 



On receiving value '01' of RF error indicator, the host shall interpret the received data having an 
error. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.3 Registries 

5.7.2.3.1 Type A reader RF gate 

5.7.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.1. 



R01 



The host shall adhere to the access condition of RO for DID. 



R02 



The host shall adhere to the access condition of RO for ATQA. 



R03 



The host shall adhere to the access condition of RO for APPLICATION DATA. 



R04 



The host shall adhere to the access condition of RO for SAK. 



R05 



The host shall adhere to the access condition of RO for FWI, SFGT. 



R06 



The host shall only set values of DATARATE_IVIAX as specified in TS 102 622 [1] 
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NOTE 1: Conformance to ISO/IEC 14443-3 [4] and ISO/IEC 14443-4 [5] of the values written by the host is out of 
scope of the present document. 

NOTE 2: Development of test cases for above listed RQs is FFS. 

5.7.2.3.2 Type B reader RF gate 

5.7.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.2. 



RQ1 


The host shall adhere to the access condition of RO for PUPI. 


RQ2 


The host shall adhere to the access condition of RO for APPICATION DATA. 


RQS 


The host shall adhere to the access condition of RO for HIGHER LAYER RESPONSE. 



NOTE 1: Conformance to ISO/IEC 14443-3 [4] and ISO/IEC 14443-4 [5] of the values written by the host is out of 
scope of the present document. 

NOTE 2: Development of test cases for above listed RQs is FFS. 

5.7.2.4 Events and subclauses 

5.7.2.4.1 Events 

5.7.2.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.2.4.2 EVT_READER_REQUESTED 

5.7.2.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.1. 
|RQ1 [When the host sends EVT_READER_REQUESTED, it shall contain no parameters. ~| 

NOTE: Development of test cases for above listed RQs is FFS. 

5.7.2.4.3 EVT_END_OPERATION 

5.7.2.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.2.5 Responses 

5.7.2.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.5. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.7.3 Reader application gates 

5.7.3.1 Overview 

Reference: TS 102 622 [1], clause 10.3.1. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.3.2 Command 

5.7.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.2. 
There are no conformance requirements for the UICC for the referenced clause. 

5.7.3.3 Registry 

5.7.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.3. 



RQ1 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.3.4 Events and subclauses 

5.7.3.4.1 Events 

5.7.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4. 



I RQ1 [The reader application gates support the event name EVT_TARGET_DISCOVERED. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.3.4.2 EVT_TARGET_DISCOVERED 

5.7.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4.1. 
There are no conformance requirements for the UICC for the referenced clause. 
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5.7.4 Procedures 



5.7.4.1 



Use of contactless reader application 



5.7.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.4.1. 



RQ1 



The host shall send the EVT_READER_REQUESTED event on a single pipe only. 



RQ2 



In the context of a valid contactless reader application sequence as specified in TS 102 622 [1], the host 
shall only send WR_XCHG_DATA commands after receiving an EVT_TARGET_DISCOVERED event 
which indicates that there is a single target in the reader field. 



RQ3 



In the context of a valid contactless reader application sequence as specified in TS 102 622 [1], if the 
host receives an EVT_TARGET_DISCOVERED event which indicates that there are several targets in 
the field, the host shall not send WR_XGHG_DATA commands. 



RQ4 



If the host sends the EVT_END_OPERATION event, it shall send it on a single pipe only. 



RQ5 



In the context of a valid contactless reader application sequence as specified in TS 102 622 [1], if the 
host sends an EVT_END_OPERATION event, it shall not send further WR_XCHG_DATA commands 
until it has received a further EVT TARGET DISCOVERED event. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.8 Connectivity 



5.8.1 Overview 

Reference: TS 102 622 [1], clause 11.1. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.2 Connectivity gate and subclauses 
5.8.2.1 Connectivity gate 

Reference: TS 102 622 [1], clause 11.2. 
There are no conformance requirements for the Host for the referenced clause. 



5.8.2.2 



Commands 



5.8.2.2.1 



PRO HOST REOUEST 



5.8.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.1.1. 



RQ1 



The Host shall not try to interact with any other host except the host controller before receiving the 
response of PRO_HOST_REQUEST. 



RQ2 



The Host shall not try to interact with another host if the response of PRO_HOST_REOUEST is not 
ANY OK. 



RQS 



The Host shall not try to interact with the host after the expired activation duration time. 



RQ4 



The Host shall not put the host controller or the terminal host in the list of host identifiers. 



RQS 



When the Host sends a PRO_HOST_REQUEST, it shall use at least 3 bytes parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.8.2.3 Events and subclauses 

5.8.2.3.1 Events 

Reference: TS 102 622 [1], clause 11.2.2. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.2.3.2 EVT_CONNECTIVITY 

5.8.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.1. 
|RQ1 [When the Host sends EVT_CONNECTIVITY, it shall contain no parameters. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.8.2.3.3 Void 

Reference: TS 102 622 [1], clause 11.2.2.2. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.2.3.4 EVT_OPERATION_ENDED 

5.8.2.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.3. 



RQ1 



When the Host send EVT_OPERATION_ENDED. it shall not contain parameters. 



RQ2 



The Host shall only EVT_OPERATION_ENDED in the context of a PRO_HOST_REQUEST command. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8.2.3.5 EVT_TRANSACTION 

5.8.2.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.4. 



RQ1 



When the Host sends the EVT_TRANSACTION, it shall use BER-TLV parameters as defined in 
TS102 622[1]. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8.2.4 Registry 

5.8.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.3. 



RQ1 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.8.3 Connectivity application gate and subclauses 

5.8.3.1 Connectivity application gate 
5.8.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.3.2 Commands 

5.8.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.1. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.3.3 Events and subclauses 

5.8.3.3.1 Events 

5.8.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.3.3.2 EVT_STANDBY 

5.8.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2.1. 



RQ1 



When the Host receives the EVT_STANDBY, it shall stop any ongoing communication with the other 
hosts and the host controller within 1 00 ms. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8.3.4 Registry 

5.8.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.3. 
There are no conformance requirements for the Host for the referenced clause. 

5.8.4 Procedures 

5.8.4.1 Use of connectivity gate 

Reference: TS 102 622 [1], clause 11.4.1. 
There are no conformance requirements for the Host for the referenced clause. 
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